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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Access, Terminals, Transmission 
and Multiplexing (ATTM). 



Introduction 

The present document defines the requirements of a Network Termination (NT) device for Next Generation Access 
Networks in different technologies. 

Because many options for such a device are feasible, depending on the access network technology, the business 
scenario, the regulatory constraints, etc., the present document provides a superset of the requirements for a Layer 2 
Network Termination: a specific NT device implementation may be derived by selecting the appropriate subset of 
technical requirements. 

The present document is organized as list of possible clauses for a joint specification to be used as Request for 
Information and to extract contributions to be submitted to different Fora and Standardization bodies. 

Business Rationale 

As the next step in the evolution of Access Networks, it is foreseen that higher bandwidth services will be delivered, 
either with active network elements built closer to the end-user (e.g. VDSL or Point-to-Point FTTH technology), or at 
the opposite end with active elements more distant from the end-user (e.g. GPON FTTH technology). Due to the 
deployment of new access networks, network operators are faced with technological, operational, financial and also 
regulatory challenges. 

The development of a Layer-2 Network Termination (NT) device at the customer premises location for Next 
Generations Networks is related with the deployment of new very high broadband network access infrastructure and the 
need to ensure a competitive market for retail services. Since the investment for those deployments is very high, it is 
expected that only a very limited number of operators can build the infrastructure. 

For this reason, in deployment scenarios where the investment in (part of) the infrastructure has geographically only 
been made by a single Access Network Provider (ANP), a wholesale offer like "Ethernet Bitstream" will contribute to 
create a competitive market for retail services. This will allow more Service Providers to offer services to end users 
through a standard and unique Access Network-Home Network interface (Ethernet interface). The Ethernet Bitstream 
offering can be considered as a Layer-2 transport service from the end-user location to the Point of Presence (PoP) of 
the Broadband Service Provider (BSP), as an alternative to sub-loop unbundling. Then the BSP supplies the end user IP 
connectivity and optionally application services of its own or of other application service providers (ASP). At the 
contrary, in deployment scenarios where several companies have invested in broadband network access infrastructure in 
a given geographical area, retail services competition is provided by sub-loop unbundling and therefore wholesale offer 
like "Ethernet Bitstream" is not required. 
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The following scenarios can be considered: 



1) Multiple access network providers in a given area/Single network operator per customer: each access 
network is owned by an operator offering its own bundle of services; the customer can churn from one 
operator to another. 

In this scenario the NT is not strictly mandatory as a stand-alone device. The operator can provide an 
integrated CPE device (Home Gateway) to its customer in order to terminate the xDSL or fiber optic link and 
to deliver its services. 

2) Single access network provider in a given area/Multiple BSP per customer: this scenario refers to a single 
open access network, owned by an ANP, providing open and equal access to many BSP that may 
simultaneously offer services to each customer via multiple virtual Ethernet connections. 

In this scenario the presence of the NT owned by the ANP is mandatory. The NT provides standard Ethernet 
multi-port interface(s) to the BSPs, with one (or more) different port(s) for each BSP. Each BSP can provide 
terminals (Home Gateway, Analogue Telephony Adapters, VoIP phones, IPTV Set Top Box) to its customer 
in order to deliver its services. 

In any case, the deployment of a NT with standard Ethernet interface enables the definition of service models where 
other Customer Premises Equipment (CPE) and terminals are provided by the BSP or alternatively can be purchased on 
the retail market by the customer. 

Both scenarios have a different impact on the requirements of the NT, but it is expected that having a NT device would: 

• define a clear interface to allow the separation of responsibilities between the BSP and the ANP; 

• help an ANP, providing wholesale services, to troubleshoot directly the end point of the access network at the 
NT-side, allowing end-to-end service assurance on the NGAN; 

• allow the evolution of home networks and all IP-based services independently from the FTTx access network 
technology. 

However, since the NT is a L2 device, in case of multi-BSP-per-customer there are the following limitations: 

• a separate IP home subnetwork corresponds to each different BSP offering, so the customer cannot benefit 
from a single home network, and interaction between services of different broadband service providers are 
impossible within the home network; 

• internal home network cabling becomes increasingly complex, if differentiation of broadband service 
providers is made through different physical interfaces; 

• the ANP needs to strictly isolate each BSP L2 flow, and cannot benefit from statistical multiplexing on the 
local (sub)loop and on the aggregation network. 

In conclusion, the multi-BSP-per-customer scenario provides the following features: 

• free choice for the customer to compose its own bundle of services from different BSPs; 

• separation of responsibilities between the ANP investing in the infrastructure (responsible of the access 
network, including the NT) and the different BSPs (responsible of the home network and the services provided 
to the end customer). 

Figure 1 describes the reference architecture related to the use of a Network Termination device with standard Ethernet 
interface and different CPEs at the customer site. 
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ANP provides and maintains the NT 
with the Access Network technology at 
that customer site (e.g. VDSL2) 




By means of a residential Home 
Gateway with different integrated or 
externally added LAN technologies 
(e.g. WLAN, PLT), a home 
network may be created and 
mainteined by the BSP 



The wholesale service at the ANP-BSP 
interface remains unchanged (e.g. 
Ethernet L2 bitstream), also upon 
upgrades of Access Network and NT 



A terminal device may 
offer services such as 
VoIP and IPTV 



Figure 1 : Reference architecture for use of a Network Termination in NGN 

NT high-level functionalities 

The main features of the NT device, that are defined in the present document, are: 

• termination of the access network at the customer premise, whatever access technology is used (ADSL2+, 
VDSL2, GPON, Point-to-Point FTTH with lOOBase-BX): 

when existing twisted pair Hnes and VDSL2 technology is used in the access, NT is self-installing by the 
customer on the existing POTS/ISDN termination connector; 

• it is locally powered; 

• it is under complete ownership and responsibility of the ANP, for provisioning and assurance purposes; remote 
management of the NT is a possible feature; 

• it is equipped with (at least) one standard LAN-technology Ethernet interface, for the interconnection to 
CPE/Home Gateways/Terminals provided by BSPs or ASPs; 

• it may be equipped with more than one physical LAN Ethernet interface in order to enable multiple service 
devices and multi-BSP offerings; 

• it supports VLAN traffic segregation and related functionalities; 

• optionally, it may provide upstream QoS functionalities to enable L2 bitstream services; this feature is 
especially needed when there is a bottleneck in the upstream, more relevant in case of xDSL access; 

• optionally, it may be remotely managed (firmware upgrade included). 
The following functionalities are not required for the NT device: 

• lifeline in case of power interruption; 

• VoIP/FXS ports and related functionalities; 

• any other LAN interfaces except Ethernet; 
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• in case of multiple-BSP scenario, the intra-LAN connectivity between devices connected to different BSPs (in 
this case, the communication between these devices will use the WAN interface and geographical network). 

Such a NT device may support a wholesale business model for L2 bitstream services over the Next Generation Access 
Network. 

Reference block diagram for NT 

In the present document, the possible functionalities of the NT device are organized in a set of functional blocks, that 
may be included or not included in the device depending upon specific implementations and deployments. 
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Figure 2: Reference block diagram for the Network Termination device 

As outlined in figure 2, the functional blocks of the NT device are the following: 

• Physical user interface, as defined in the general requirements of the NT device (clause 4), including LEDs 
and buttons/switches. 

• WAN physical interface (clause 5), that must be either xDSL, GPON or Point-to-point FTTH. The logical 
framing on the WAN interface (clause 6) is L2 Ethernet, but in case of xDSL/ADSL2+ also ATM framing 
must be supported. 

• Ethernet LAN interface (clause 7), that must be equipped with either a single LAN port (single service 
provider scenario) or with multiple LAN ports (multiple service provider scenario). 

• IP functionalities (clause 8) are not required, except when a TCP/IP based remote management feature is 
requested. 

• LAN- WAN QoS functionalities for the upstream traffic (clause 9), may be required, e.g. in case of VDSL2 
NT with multiple LAN ports. 

• The remote management functional block (clause 1 1) is optional and may be implemented with different 
solutions, depending upon the access technology on the WAN interface. 
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Scope 



The present document describes a proposal of requirements for a Network Termination (NT) device in Next Generation 
Access Networks. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 



2.1 



Normative references 



The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 



[1] 
[2] 
[3] 



CENELEC EN 50173-1 (2007): "Information technology - Generic cabling systems - 
Part 1: General requirements". 

CENELEC EN 50173-4 (2007): "Information technology - Generic cabling systems - 
Part 4: Homes". 

DSL Forum TR-124 (December 2006): "Functional Requirements for Broadband Residential 
Gateway Devices". 



NOTE: Available at: www.dslforum.org/techwork/tr/TR- 1 24.pdf . 

[4] DSL Forum TR-068 (May 2004): "Base Requirements for an ADSL Modem with Routing". 

NOTE: Available at www.dslforum.org/aboutdsl/Technical Reports/TR-068.doc . 
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2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] Council Directive 89/336/EEC of 3 May 1989 on the approximation of the laws of the Member 

States relating to electromagnetic compatibility. 

[i.2] Directive 1999/5/EC of the European Parliament and of the Council of 9 March 1999 on radio 

equipment and telecommunications terminal equipment and the mutual recognition of their 
conformity. 

[i.3] Council Directive 73/23/EEC of 19 February 1973 on the harmonization of the laws of Member 

States relating to Electrical Equipment designed for use within certain voltage limits. 

[i.4] Council Directive 93/68/EEC of 22 July 1993 amending Directives 87/404/EEC (simple pressure 

vessels), 88/378/EEC (safety of toys), 89/106/EEC (construction products), 89/336/EEC 
(electromagnetic compatibility), 89/392/EEC (machinery), 89/686/EEC (personal protective 
equipment), 90/384/EEC (non-automatic weighing instruments), 90/385/EEC (active implantable 
medicinal devices), 90/396/EEC (appliances burning gaseous fuels), 91/263/EEC 
(telecommunications terminal equipment), 92/42/EEC (new hot- water boilers fired with liquid or 
gaseous fuels) and 73/23/EEC (electrical equipment designed for use within certain voltage limits). 

[i.5] IEEE 802. 3ah: "IEEE Standard for Information Technology - Telecommunications and 

information exchange between systems - Local and metropolitan area networks - Specific 
requirements - Part 3: Carrier Sense Multiple Access With Collision Detection (CSMA/CD) 
Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, 
Physical Layers, and Management Parameters for Subscriber Access Networks". 

[i.6] IETF RFC 2684: "Multiprotocol Encapsulation over ATM Adaptation Layer 5". 

[i.7] IEEE 802. Ip: "Standard for Local and Metropolitan Area Networks - Supplement to Media Access 

Control (MAC) Bridges: Traffic Class Expediting and Dynamic Multicast Filtering". 

[i.8] ISO/IEC 8802-3: "Information technology - Telecommunications and information exchange 

between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier 
sense multiple access with collision detection (CSMA/CD) access method and physical layer 
specifications". 

[i.9] IEEE 802. lag: "IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local 

Area Networks Amendment 5: Connectivity Fault Management". 

[i.lO] ITU-T Recommendation G.984 (all parts): "Gigabit-capable Passive Optical Networks (GPON)". 

[i.l 1] IEEE 802. Iq: "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local 

Area Networks". 

[i. 12] ITU-T Recommendation K.21 : "Resistibility of telecommunication equipment installed in 

customer premises to overvoltages and overcurrents". 

[i.l 3] ITU-T Recommendation K.44: "Resistibility tests for telecommunication equipment exposed to 

overvoltages and overcurrents - Basic Recommendation". 

[i.l4] ITU-T Recommendation G.992.1: "Asymmetric digital subscriber line (ADSL) transceivers". 

[i.l5] ITU-T Recommendation G.992.3: "Asymmetric digital subscriber line transceivers 2 (ADSL2)". 

[i.l 6] ITU-T Recommendation G.992.5: "Asymmetric Digital Subscriber Line (ADSL) transceivers - 

Extended bandwidth ADSL2 (ADSL2plus)". 

[i.l7] ITU-T Recommendation G.997.1: "Physical layer management for digital subscriber line (DSL) 

transceivers". 
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1.18] ITU-T Recommendation G.994.1: "Handshake procedures for digital subscriber line (DSL) 

transceivers". 

1.19] ITU-T Recommendation G.993.2: "Very high speed digital subscriber Hne transceivers 2 

(VDSL2)". 

1.20] ITU-T Recommendation 1.361: "B-ISDN ATM layer specification". 

1.21] ITU-T Recommendation 1.365: "B-ISDN ATM adaptation layer sublayers". 

1.22] DSL Forum WT-1 15: "G.VDSL2 Functionality Test Plan". 

1.23] DSL Forum TR-067: "ADSL Interoperability Test Plan". 

1.24] DSL Forum TR-100: "ADSL2/ADSL2plus Performance Test Plan". 

1.25] DSL Forum WT-105: "G.992.3/5 ADSL2/ADSL2plus Functionality Test Plan". 

1.26] DSL Forum WT-1 14: "G.VDSL2 Performance Test Plan". 

1.27] DSL Forum WT-107: "Internet Gateway Device Data Model Version 2" (includes bonded DSL). 

i.28] DSL Forum TR-098: "DSLHome^M Internet Gateway Device Version 1 . 1 Data Model for 

TR-069". 

1.29] DSL Forum TR-069: "CPE WAN Management Protocol" . 

1.30] DSL Forum PD-128: "Test Plan for TR-069 Plugfests". 

1.31] SFF-8472: "Specification for Diagnostic Monitoring Interface for Optical Transceivers". 

NOTE: Available at: r ftp://ftp.seagate.com/sff/SFF-8472.PDF]. 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ADSL Asymmetric Digital Subscriber Line 

AES Advanced Encryption Standard 

AN Access Network 

ANP Access Network Provider 

ATM Asynchronous Transfer Mode 

BER Bit Error Rate 

BSP Broadband Service Provider 

GBR Constant Bit Rate 

CO Central Office 

CoS Class of Service 

CPE Customer Premises Equipment 

DBRu Dynamic Bandwidth Report upstream 

DHCP Dynamic Host Configuration Protocol 

DSCP DiffServ Code Point 

DSLAM Digital Subscriber Line Access Multiplexer 

EFM Ethernet in the First Mile 

EMC Electric Magnetic Compatibility 

FE Fast Ethernet 

EEC Forward Error Correction 

FTTH Fiber To The Home 

FTU Fiber Termination Unit 

FXS Foreign eXchange Station 

GEM G-PON Encapsulation Method 

GPON Gigabit Passive Optical Network 

ID Identifier 

IGMP Internet Group Management Protocol 
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IPTV Internet Protocol Television 

ISDN Integrated Services Digital Network 

LAN Local Area Network 

LED Light Emitting Diode 

MIB Managed Information Base 

MTBF Mean Time Between Failure 

NGAN Next Generation Access Network 

NGN Next Generation Network 

NRZ Non Return to Zero 

NT Network Termination 

0AM Operations, Administration & Maintenance 

OMCI ONT Management Control Interface 

ONT Optical Network Termination 

ONU Optical Network Unit 

P2P Point to Point 

PBO Power Back-Off 

PoP Point of Presence 

POTS Plain Old Telephone Service 

PSD Power Spectral Density 

PTM Packet Transport Mode 

PVC Permanent Virtual Connection 

QoS Quality of Service 

SP Strict Priority 

T-CONT Transmission Container 

TCP/IP Transmission Control Protocol/Internet Protocol 

ToIP Telephony over IP 

ToS Type of Service 

UBR Unspecified Bit Rate 

USB Universal Serial Bus 

VBR Variable Bit Rate 

VCI Virtual Connection Identifier 

VDSL Very high bit-rate Digital Subscriber Line 

VLAN Virtual Local Area Network 

VoIP Voice over IP 

VPI Virtual Path Identifier 

VTU VDSL Transceiver Unit 

WAN Wide Area Network 

WDM Wave Division Multiplexing 

WFQ Weighted Fair Queuing 



General requirements 



4.1 



Hardware and case characteristics 



Specific requirements: 

1) Customized case (the case will be customized by each operator) with small form factor, also allowing 
wall-mount. Specific recommended dimensions, in case of xDSL WAN-side technology, are 5x5x2 cm. 

In case of optical WAN-side technology, no specific dimensions are defined (mainly determined by the size of 
the Fiber optic cabling protective storage space, as minimum bend radius). 

2) [GPON] [PtP FTTH] The design of the NT shall provide a mechanism that protects the fiber optic cabling 
against tampering by the end user. This can be realized by a functional component of the NT-housing which is 
referenced by as the Fiber Termination Unit (FTU). For the FTU the following requirements apply: 

The FTU shall provide a fool proof and robust method of interconnection with the NT active 
component/module ("mount and click" system without any fiber optic cabling between the FTU and NT). 
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The NT (module) shall be easily interchangeable without dismounting or dismantling the FTU exposing 
the fiber optic cabling. 

The FTU (including the mounted NT) shall support a robust wall-mounted installation with all 
connectors facing downward or sideward. 

The FTU shall provide a scalable protective storage space that fits an excess length of 1 meter for two 
fiber optical cables (one spare and one in use). 

It shall be possible for service operator to access and use the spare fiber without disrupting the service on 
the first fiber. 

The FTU shall have a pull relief for the fiber ducts or fiber cables. 

The FTU shall be fitted with a lock-mechanism or seal to prevent un-authorized access to the fiber optic 
cabling. 

It shall be possible to open the FTU without removing the NT and disrupting the service. 

3) The following LED indicators must be present: 

1 LED for power. 

1 LED for VDSL2/GP0N/PtP FTTH interface status. 

1 LED for each Ethernet port. 

Color, behavior and meaning of different LED status must be compliant with following DSL Forum 
TR 124 [3] requirements: 

REGIONAL.NA.LED. 7 (LED visibility). 

REGIONAL.NA.LED. 8 (duty cycle). 

REGIONAL.NA.LED. 9 (power indicator). 

REGIONAL.NA.LED. 9 (WAN interface status). 

REGIONAL.NA.LED. 13 (LAN interfaces status). 

4) [VDSL2] Start-up time: the NT must be fully operational and begin the VDSL2 hand-shaking phase within 
5 seconds. 

5) [GPON] [PtP FTTH] Start-up time: the NT must be fully operational within 5 seconds. 

6) The minimum MTBF should be at least 220 000 hours. 

7) [OPTIONAL], The NT shall have an on/off hardware button for switching on/off the device. 

8) Optionally, the NT shall have a hardware button that allows a two-step reset process: 

renewal of its DHCP-configuration, if any (i.e. pressing the button for less than 5 seconds); 
return to factory default settings (i.e. pressing the button for more than 5 seconds). 

9) If present, the design of the hardware button (bullet 7) shall prevent accidental activation. 

4.2 Powering characteristic 

Specific requirements: 

10) The power supply MUST be external, in switching (not linear) technology and connected to the device using a 
connector. 

11) The contra-connector on the NT-housing MUST contain a pull relief mechanism that prevents accidental 
removal of the power supply connector. 
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12) The external power supply MUST operate with AC mains supply rate voltage at 50 Hz to 60 Hz between at 
least 110 Vac (-10 % as tolerance) and 240 Vac (+6 % as tolerance). 

13) The power efficiency of the external power supply must be compliant with Code of Conduct External Power 
Supply version 2 November 2004. 

14) The power absorbed by the power supply in not load (NT in off position or disconnected from power supply) 
condition MUST be lower than 0,3 W. 

15) The NT power consumption must be compliant to the European Code of Conduct for broadband devices 
[European Commission "Code of Conduct on Energy Consumption of Broadband Equipment (version 1.2)" - 
April 2007 Draft], annex B.l Tier 2 related to 2008 timeframe]: 

For ADSL-only the maximum power must be lower than 4 W. 

For VDSL2 the maximum power must be lower than 6 W. 

In case of multiple Ethernet LAN ports, the maximum additional power must be less than 2 W. 

For GPON modems, version 2 of the Code of conduct ( http://re.jrc.cec.eu.int/energyefficiency/) issued 
the 17th of July 2007 advertises some values to be applicable from 2009. firstly they apply to an ONT 
comprising 1 GPON interface, 1 10/100/1000 Ethernet UNI port and 1 USB device. 

0,3 W Off position max consumption. 

12 W Max in operation. 

TBD (to be defined) stand by mode consumption. 

4.3 Electrical and Mechanical Protection, Safety, EMC and 
Environmental Safety (Eco-Compatibility) 

In case of no other country- specific requirements are provided, the following specific requirements apply. 

16) The device shall meet all essential technical requirements under the EMC Directive 89/336/EEC [i.l], to 
ensure an adequate level of Compatibility for apparatus intended to be used in the residential environments. 

17) The device and all the included accessories shall be constructed in order not to be dangerous for users, service 
personnel and in order to reduce the risk of fire. Such requirements are defined "essentials", so mandatory, by 
European Directives 1999/5/EC [i.2], 73/23/EEC [i.3] "Low Voltage Directive" and 93/68/EEC [i.4] "CE 
Marking". 

18) The device shall comply with requirements defined by ITU-T Recommendations K.21 [i.l2] and K.44 [i.l 3]. 

19) The device in case of optics shall be designed so as to insure safety of end user's eyes. 

In order to minimize risks of disturbance between systems, in contexts where several transmission technologies will 
have to co-exist, solutions are requested to avoid that mis-insertion of one modem type could harm the system already 
running on the medium itself (shared medium). In particular, it must be avoided that a P2P optical NT, if plugged by 
error on a GPON access, disturbs transmission for all other users connected to the same PON 

20) [OPTICAL, applicable in contexts where several transmission technologies will have to coexist] The NT must 
keep its transmitter disabled (or at minimum transmit power), till it recognizes data required from the MAC 
synchronizing pattern in the downstream flow from LT. Then on, proper link layer negotiation can start. 
This solution will have to be discussed with system vendors to confirm feasibility without prohibitive extra 
cost, and shall preferably have no impact on the IEEE 802. 3ah [i.5] Physical Medium Dependent sublayer 
specifications that are applicable for P2P architectures. 



ETSI 



1 4 ETSI TS 1 02 973 V1 .1 .1 (2008-09) 



WAN physical interfaces 



The following different and alternative options for the NT WAN interface are addressed by these requirements, in order 
to support specific WAN technologies: 

ADSL2+ only. 

VDSL2 only. 

VDSL2 and ADSL2+. 

GPON. 

Point-to-point FTTH based on lOOBase-BX technology. 

A specific different NT device is foreseen to support each single WAN technology, therefore it is not required the 
support of all these technologies in a single device. 

This technology list remains open to further access options for instance WDM that can be combined with the point to 
point options listed below and will be with future PON generations. 



5.1 xDSL physical connector 



21) xDSL WAN interface with RJ-45 connector [1] and [2] with specific color coding (DSL Forum TR-068 [4] 
requirement I - 37). As an alternative, depending on regional specific requirements, RJ-11 connector may be 
used. In order to facilitate compatibility with regional specific requirements, it is recommended to adopt in the 
NT a female RJ45 connector able to accept both RJ45 and RJl 1 male connectors alternatively. 



5.2 ADSL2+ specific characteristics 



22) The NT must conform to ITU-T Recommendation G.992.1 [i.l4], (ADSL) annex A, ITU-T Recommendation 
G.992.3 [i.l5], (ADSL2) annex A and ITU-T Recommendation G.992.5 [i.l6], (ADSL2plus) annex A. 

23) The NT must be able to guarantee, in the interworking with the DSLAM platforms, at least the same ADSLl 
performances as requested in DSL Forum TR-067 issue 2 [i.23], related to ITU-T Recommendation 
G.992.1 [i.l4], annex A European systems. 

24) The NT must be able to guarantee, with reference to DSLAM platforms, at least the same ADSL2 and 
ADSL2plus performances as requested in DSL Forum TR-100 [i.24] and in the latest version of DSL Forum 
WT-105 [i.25], related to ITU-T Recommendations G.992.3 [i.l5] and G.992.5 [i.l6], annex A European 
systems. 

25) The device must be conform to ITU-T Recommendation G.997.1 [i.l7], with specific regard to the following 
issues: 

ITU-T Recommendation G.997.1 [i.l7], section 7.3.1.3: configuration and control of transmitted power 
levels through appropriate tuning of DS/US SNR margin parameters; more specifically the maximum 
noise margin, target noise margin and minimum noise margin. 

ITU-T Recommendation G.997.1 [i.l7], section 7.4: management of inventory information: Vendor ID, 
System Vendor ID, Version Number, Serial Number, Self-Test Result, ADSL Transmission System 
Capabilities. 

ITU-T Recommendation G.997.1 [i.l7], section 7.5: management of the following parameters: Line test, 
diagnostics and status parameters (section 7.5.1) and Channel status parameters (section 7.5.2). 

26) The NT must be able to transmit for every DSLAM platforms supported its vendor ID according to the coding 
specified in ITU-T Recommendation G.994.1 [i.l8]. 
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5.3 VDSL2-only specific ciiaracteristics 



27) Compliancy with ITU-T Recommendation G.993.2 [i.l9]; moreover the VDSL2 Hne system must be 
compHant with ITU-T Recommendation G.993.2 [i.l9], Corrigendum 1 and Amendment 1. 

28) CompHancy with the international standards of the ITU-T: 

ITU-T Recommendation G.997.1 [i.l7], Physical layer management for digital subscriber line (DSL) 
transceivers. 

ITU-T Recommendation G.997.1 [i.l7], Physical layer management for digital subscriber line (DSL) 
transceivers (Corrigendum 1). 

ITU-T Recommendation G.997.1 [i.l7], Physical layer management for digital subscriber line (DSL) 
transceivers (Amendment 1). 

ITU-T Recommendation G.994.1 [i.l8], Handshake procedures for digital subscriber line (DSL) 
transceivers. 

ITU-T Recommendation G.994.1 [i.l8], Handshake procedures for digital subscriber line (DSL) 
transceivers (Amendment 1). 

ITU-T Recommendation G.994.1 [i.l8], Handshake procedures for digital subscriber line (DSL) 
transceivers (Amendment 2). 

29) The device must be conform to ITU-T Recommendation G.997.1 [i.l7], with specific regard to the following 
issues: 

ITU-T Recommendation G.997.1 [i.l7], section 7.3.1.3: configuration and control of transmitted power 
levels through appropriate tuning of DS/US SNR margin parameters; more specifically the maximum 
noise margin, target noise margin and minimum noise margin. 

ITU-T Recommendation G.997.1 [i.l7], section 7.4: management of inventory information: Vendor ID, 
System Vendor ID, Version Number, Serial Number, Self-Test Result, ADSL Transmission System 
Capabilities. 

ITU-T Recommendation G.997.1 [i.l7], section 7.5: management of the following parameters: Line test, 
diagnostics and status parameters (section 7.5.1) and Channel status parameters (section 7.5.2). 

30) The NT must be able to transmit for every DSLAM platforms supported its vendor ID according to the coding 
specified in ITU-T Recommendation G.994.1 [i.l8]. 

31) The NT must be able to guarantee, with reference to DSLAM platforms, at least the same VDSL2 as requested 
in latest version DSL Forum WT-1 14 [26] and in latest version of DSL Forum WT-1 15 [i.22], related to ITU- 
T Recommendation G.993.2 [i.l9], annex B European systems. 

32) Profiles supported: All profiles defined in table 6-1 of ITU-T Recommendation G.993.2 [i.l9] shall be 
supported. 

33) Bandplans supported: All bandplans defined in annex B of ITU-T Recommendation G.993.2 [i.l9], 
Amendment 1 shall be supported. 

34) Interworking with customer premises network and coexistence with POTS 

35) [OPTIONAL] coexistence with ISDN, PSD-Masks supported: All PSD masks defined in annex B of ITU-T 
Recommendation G.993.2 [i.l9] shall be supported. 

36) Co-existence of cabinet-based VDSL2 deployments with CO-based ADSL2+ deployments in the same binder: 

Interoperability with a VTU-C that uses MIB PSD mask (ITU-T Recommendation G.993.2 [i.l9], 
section 7.2). 

Downstream PSD shaping as defined in ITU-T Recommendation G.997.1 [i.l7]. 

37) Application of PBO mechanisms on both Upstream (UPBO) and Downstream (DPBO) paths, according to 
ITU-T Recommendations G.993.2 [i.l9] and G.997.1 [i.l7] methods. 
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38) The support of all tone sets defined in the amendments to ITU-T Recommendation G.994.1 [i.l8]. 

39) PTM-EFM support. 

40) The device must interwork with any VTU-C VDSL2 chipset and DSLAM technologies. 

5.4 VDSL2 and ADSL2+ specific ciiaracteristics 

The following additional requirements apply in case of VDSL2 NT with ADSL2+ backward compatibility: 

41) ADSL/ADSL2+ (ATM encapsulation) backward compatibility with full auto-sensing, in terms that no action 
on the device is needed (i.e. no reboot) during or after the switch from ADSL2+ to VDSL2 and vice- versa 
(seamless experience for the end user). 

42) ADSL/ADSL2+ support and auto-sensing feature must not limit the full support of any VDSL2 profiles, when 
working in VDSL2 mode. 

43) In case of ADSL/ADSL2+ working mode, bridging between LAN side VLANs and WAN side ATM PVCs. 

44) Different configuration profiles for ATM and PTM modes must be automatically activated by the NT, in 
relationship with VDSL2 - ADSL/ADSL2+ auto-sensing functionality (The NT must hold both configuration 
sets, for ADSL -PVCs- and VDSL2 -VLANs-). 

5.5 GPON-specific characteristics 

In the current clause, the GPON NT is referred as ONT. 

45) The GPON interface must be compliant with ITU-T Recommendation G.984 (all parts) [i.lO]. 

46) Single fiber transmission is used for optical transmission (both in the upstream and downstream direction) and 
bidirectional transmission is accomplished by use of a WDM technique called diplex defined in ITU-T 
Recommendation G.984.5 [i.lO]. 

47) The ONT supports a maximum logical reach in conformance with ITU-T Recommendation G.984. 1 [i.lO] 
(i.e. 60 km). 

Synchronization 

48) The ONT supports the use of a clock extracted from the optical interface in conformance with section 6.4.1 of 
ITU-T Recommendation G.984.3 [i.lO]. 

49) The ONT supports internal timing for holdover operation with ±20 ppm accuracy. The ONT uses the free run 
clock only if the input clock is lost. 

Line code 

50) The ONT uses NRZ coding and scrambling in both directions. 
G-PON Transmission Convergence 

51) The ONT supports a GTC that is composed by a "Framing Sublayer" and an "Adaptation Sublayer" in 
conformance with ITU-T Recommendation G.984.3 [i.lO]. 

52) The ONT realizes the mapping of GEM frames into GTC payload (and inversely extracts GEM frames from 
GTC payload) in conformance with ITU-T Recommendation G.984.3 [i.lO]. 

53) The ONT realizes the mapping of Ethernet frames into GEM frames (and inversely extracts Ethernet frames 
from GEM frames) in conformance with ITU-T Recommendation G.984.3 [i.lO]. 

54) The ONT is able to send frames according to a static allocation provisioned at the OLT. 

55) The ONT supports the Non Status Reporting mode in conformance with ITU-T Recommendation 
G.984.3 [i.lO]. 
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56) The ONT is able to provide the information to the DBA function at the OLT in order to optimize bandwidth 
allocation between ONTs/ONUs when needed. 

57) The ONT supports the Status Reporting mode in conformance with ITU-T Recommendation G.984.3 [i.lO]. 

58) The ONT supports at least DBRu mode in conformance with ITU-T Recommendation G.984.3 [i.lO]. 

59) The ONT implements the principle of T-CONT (identified by " Alloc-ID") as the basic control unit for 
upstream direction in conformance with ITU-T Recommendation G.984.3 [i.lO]. The ONT is able to support 
at least 4 T-CONTs i.e. 1 T-CONT per CoS. 

60) The ONT must support T-CONT Type 1, 2, 3 and 4. 

61) The ONT is able to use the activation Discovered SN method in conformance with ITU-T 
Recommendation G.984.3 [i.lO]. 

62) The ONT is able to use the activation Configured SN method in conformance with ITU-T 
Recommendation G.984.3 [i.lO]. 

63) The ONT uses the encryption system (128 bits AES in Counter Mode) and the Key Exchange mechanism in 
conformance with ITU-T Recommendation G.984.3 [i.lO], to be used only for unicast services. 

64) The ONT implements an "embedded 0AM channel", a "PLOAM channel" and an "OMCI channel" in 
conformance with ITU-T Recommendation G.984.4 [i.lO]. 

Upstream 

Nominal line rate: 

65) The ONT supports a 1 244 Mbps line rate. 
Optical performances: 

66) The ONT supports Class B (Optical budget, source type, transmitter range, mean launched power min, mean 
launched power max, extinction ratio, etc.) in conformance with ITU-T Recommendation G.984.2 [i.lO]. 

67) The ONT supports Class B+ (Optical budget, source type, transmitter range, mean launched power min, mean 
launched power max, extinction ratio, etc.) in conformance with ITU-T Recommendation G.984.2 [i.lO], 
Amendment 1. 

68) [OPTIONAL] The ONT is able to support upstream EEC. 
Downstream 

Nominal line rate: 

69) The ONT supports a 2 488 Mbps line rate. 
Optical performances: 

70) The ONT supports Class B (Optical budget, receiver type, maximum reflectance, BER, minimum sensitivity, 
etc.) in conformance with ITU-T Recommendation G.984.2 [i.lO]. 

71) The ONT supports Class B+ (Optical budget, receiver type, maximum reflectance, BER, minimum sensitivity, 
etc.) in conformance with ITU-T Recommendation G.984.2 [i.lO], Amendment 1. 

72) The ONT is able to support downstream EEC. 

5.6 Point-to-point FTTH specific ciiaracteristics 

73) The fiber Point-to Point WAN interface MUST be lOObase-BX (single mode fibre/bidirectional on a single 
fibre with diplex mode). 

74) lOObase-LX (single mode fibre, dual simplex fibres) MAY be used as fiber Point-to Point WAN instead of 

73). 
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75) lOOObase-BX (single mode fibre/bidirectional on a single fibre with diplex mode) MAY be used as fiber Point- 
to Point WAN instead of 73). 

76) lOOObase-LX (single mode fibre, dual simplex fibres) MAY be used as fiber Point-to Point WAN instead of 

73). 



WAN interfaces logical framing 



6.1 L2 ATM features 

These requirements apply only in case of ADSL2+ only NT and VDSL2/ADSL2+ NT. 

77) The ATM/ADSL network interface UNI must conform with ATM Forum UNI 4.0. 

78) The ATM functionalities must be compliant with ITU-T Recommendation 1.361 [i.20]. 

79) The AAL5 adaptation protocol must be compliant with ITU-T Recommendation 1.365 [i.21]. 

80) At least 20 configurable and concurrently active PVCs must be supported, in the whole range of VPIA^CI 
values. 

81) The ATM PVCs must be independently configurable in terms of ATM Transfer Capabilities. 

82) 0AM F5 RDI, AIS and loop-back functionalities must be supported. 

83) The following ATM transfer capabilities to be applied to ADSL upstream traffic (outbound from device) must 
be supported, with all the parameters indicated configurable. 

UBR (characterized by PCR). 

UBR+ (characterized by PCR, MCR). 

CBR (characterized by PCR and CDVT parameters). 

VBR-rt (characterized by PCR, SCR, CDVT, burst size parameters). 

84) Ethernet bridging RFC 2684 [i.6] for ATM between LAN and the WAN interface must be supported 

85) IPoEoA and PPPoEoA protocol stack support and relate IP-based functionalities as described in clause 8 IP 
functionalities. 

6.2 L2 Ethernet features 

These requirements apply in case of xDSL interfaces operating in PTM mode, GPON and point-to-point FTTH. 

86) The NT shall at least support 1 534 bytes Ethernet Frame Size (1 500 bytes data size + PPPoE header 8 bytes, 
Ethernet header 18 bytes, and two VLAN tags 2x4 bytes). 

87) VLAN support with 802. Iq tagged frames containing priority-tagged information (IEEE 802. Ip [i.7]). 

88) No limitations in VLAN numbering. The full range of 4 094 VLAN IDs can be used on the WAN interface. 

89) A minimum of 8 concurrent active VLANs MUST be supported on the WAN interface, in case of single LAN 
port NT. 

90) A minimum of 20 concurrent active VLANs should be supported on the WAN interface, in case of multiple 
LAN port NT. 
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6.3 Performances 

91) All interfaces shall support line rates data (for GPON, Fast Ethernet and Gigabit Ethernet interfaces). 

92) [xDSL and P2P] The processing power should be sufficient to support maximum WAN-technology specific 
line speeds (at least 100 Mbps full-duplex, for Fast Ethernet WAN) with all VLAN and QoS features active, 
for all Ethernet frame size and for all processing complexity at Layer 2 and VLAN handling. 

93) [GPON] The processing power should be sufficient to support a sustainable throughput of 500Mbit/s between 
its WAN and LAN interfaces, for all Ethernet frame size and for all processing complexity at Layer 2 
including VLAN handling. 

7 LAN interfaces 

7.1 Single LAN port 

The following specific requirements apply for any NT option, and basically in case of single LAN Ethernet port. 

94) One Ethernet 10/lOOBaseT ports, according to ISO/IEC 8802-3 [i.8] standard, autosensing (10/100) and with 
MDIX functionalities. 

95) Gigabit Ethernet must be supported in case of GPON WAN interface. Optional in case of other WAN 
technologies. 

96) Bridging LAN- WAN for L2 Ethernet connectivity (with both PTM and ATM encapsulation modes on WAN). 

97) Support of VLAN 802. Iq protocol (VLAN-ID and 802. Ip) on the LAN interface. 

98) No limitations in VLAN numbering. The full range of 4 094 VLAN IDs can be used on the LAN interface. 

99) Minimum of 8 concurrent active VLANs supported on the LAN interface. 



7.2 Multiple LAN ports 



These additional requirements, with respect to clause 7.1 Single LAN port, apply in case of multiple LAN Ethernet 
ports. 

100) Four Ethernet 10/lOOBaseT ports, according to ISO/IEC 8802-3 [i.8] standard, autosensing (10/100) and with 
MDIX functionalities. 

101) Gigabit Ethernet must be supported on the LAN interfaces in case of GPON WAN interface. Optional in case 
of other WAN technologies. 

102) [OPTIONAL] More Ethernet ports must be allowed to be configured with the same VLAN ID on LAN side, 
with local (LAN-to-LAN) L2 switching enabled. 

103) [OPTIONAL] In case if configuration described in 102) IGMP snooping must be available (in case of a IGMP 
request from a host connected to a first port, the multicast traffic must not be forwarded to any other LAN port 
with the same VLAN ID but no IGMP request). 

104) A single Ethernet port must be independently configurable as "Trunk", defining the VLANs allowed on the 
trunk and discarding all the remaining incoming traffic (ingress traffic from LAN already marked with VLAN 
ID). 

105) A single Ethernet port must be independently configurable as "Access", encapsulating all incoming traffic 
(decapsulating all outgoing traffic) with a 802. Iq VLAN header (ingress traffic from LAN not marked with 
VLAN ID). 

In the VLAN header both VLAN-ID field and 802. Ip field must be independently assignable on the "Access" 
ports. 
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106) [OPTIONAL] A single Ethernet port must be independently configurable as mixed "Trunk"/" Access" 
configuration: 

Forwarding all the VLANs allowed on the trunk. 

Discarding all the traffic from not-allowed VLANs. 

Encapsulating all the untagged ingress traffic (and decapsulating the egress traffic) in a different specific 

VLAN. 

107) All configurations described in 104), 105) and 106) must be available independently for each Ethernet port. 

108) [OPTIONAL, appHes to multi-port VDSL2 or Point- to -Point FTTH] VLAN Translation capability on the LAN 
FE ports configured as "Trunk". The device must be able to rewrite the VLAN-ID field of the 802. Iq header 
on the basis of an internal table, with entries based on physical FE port, ingress VLAN, egress VLAN. 

109) Minimum of 4 concurrent active VLANs supported on each VLAN-tagged LAN interface. 



8 IP functionalities 

8.1 IP traffic generated inside tine NT for communication witin 
tine network 

These functionalities are for the support of IP traffic between NT (applies to xDSL and PtP FTTH NTs only - not 
required for a pure GPON NT which is fully be managed by OMCI) and network, for Remote Management 
communication between NT and remote management system. 

110) L3 IPv4 protocol stack for assuring basic NT network connectivity at the IP layer to the Network. 

111) [OPTIONAL] L3 IPv6 protocol stack for assuring basic NT network connectivity at the IP layer to the 
Network. 

112) WAN-side DHCP client, in order to obtain an IP address directly from the network DHCP server and use a 
IPoE encapsulation. 

113) [OPTIONAL] PPPoE client and encapsulation, in order to obtain an IP address through the authentication 
process, with username/pas sword of the PPPoE session pre-configured in the default configuration or related 
to the NT itself (e.g. derived from MAC address). 

1 14) A specific connectivity model among the ones defined in 1 12) and 113), must be enabled on a factory default 
configuration basis. 

115) The equipment will be addressed with its own IP address. 

116) The traffic from/to the internal IP address is transmitted/received on a specific VLAN dedicated to the NT and 
not forwarded on the LAN side (the use of this specific VLAN ID must be forbidden on LAN side). 

117) Traffic generated within the NT must be marked with one or more 802. Ip UPB values, according to the 
application (i.e. remote management protocol, ToIP traffic if supported, etc.) [OPTIONAL marking 
differentiation on application basis] and submitted to QoS treatment as upstream traffic coming from LAN 
interfaces. 

8.2 IP traffic between LAN and WAN 

118) The NT must be fully transparent to IP traffic coming from the LAN. 

119) It must be possible to enable the p-bit tagging based on the DSCP bits of the IP ToS byte for untagged ingress 
traffic, according to the following rules: 
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LAN-WAN QoS functionalities 



This applies to the upstream data flow because the QoS poHcies of the downstream traffic are appHed in the first access 
network element that forwards the IP traffic. 

120) Traffic classification on the aggregated LAN ingress traffic based on the following physical/L2 parameters: 

VLAN-ID (for VLAN tagged traffic only). 

802. Ip UPB (for VLAN tagged traffic only). 

DSCP. 

IP Precedence. 

Physical FE port. 

And any combination of them. 

121) For ATM based WAN connections it must be possible to assign the classified flows to an ATM PVC. 

122) Marking/remarking of 802. Ip must be performed after traffic classification. 

123) Marking/remarking of DSCP/IP Precedence must be performed after traffic classification. 

124) [OPTIONAL, applies in case of multi -provider configuration with xDSL (see note)] Two-rate policing 
mechanism with two thresholds (Peak, Guaranteed), independently configurable via remote management (in 
terms of absolute bandwidth and as ratio respect to the physical line rate), for all the Service Class identified as 
a result of the traffic classification mechanism. 

NOTE: Not required for single-LAN port NT or high-speed upstream link. In any case, the Policing will be 
generally implemented in the DSL AM on a per VLAN (service) basis. The requirement will be 
considered as mandatory in case of specific needs to protect the end-user himself or services offered to 
the end user by different service providers. 

125) [OPTIONAL, applies in case of multi-provider configuration with xDSL (see note)] As a result of the two-rate 
policing mechanism, the following actions must be performed on any Service Class, according to the 
configuration (via remote management) of the NT: 

A default action to assign the traffic to be forwarded (Conform- Action). 

[OPTIONAL] A policy of 802. Ip re-mapping for the packets identified between guaranteed and peak 
threshold (Exceed-action). 

A policy of discard for the packets that overflow the peak threshold (Violate-action). 

126) [OPTIONAL, applies in case of multi-provider configuration with xDSL (see note)] Statistics must be 
provided for monitoring the traffic result of conforming, partial conforming and non conforming actions. 

127) Upstream queuing mechanism: 

Up to 4 upstream queues must be supported. 
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The association between the queues and Service Classes (one or more) must be configurable (via remote 
management, see specific requirements in clause 11 Management). 

128) The queuing mechanism must support at least 2 SP (Strict Priority) queues. 

129) The queuing mechanism must support at least 2 WFQ (Weighted Fair Queuing) queues. 

130) The weights for the WFQ queues must be configurable (via remote management). 

131) The upstream Queuing mechanism must be configurable (via remote management) as a combination of SP and 
WFQ. 

132) Statistics must be provided for monitoring the QoS traffic, both transmitted and dropped. 



10 Security 



133) [GPON] AES encryption as defined in ITU-T Recommendation G.984.3 [i.lO] is required for the unicast 
services in the downstream direction. 

134) [GPON] The ONT must be able to filter upstream IGMP requests based on white and black lists of multicast 
groups (defined by both source and destination IP address and placed by the OLT through appropriate OMCI 
messages) that will allow subscribers to request only multicast streams from the white list or any multicast 
stream except from the black list. 



1 1 Management 



If the remote management option is included in the required set of functionalities, this may be implemented either using 
a full-feature TCP/IP based solution, as specified in clause 1 1.3 TCP/IP based remote management and applicable to 
xDSL, or an access-specific 0AM solution, as specified in clause 12.1 for all access technologies, clause 11.4 
Alternative management solution for Point- to -Point FTTH for Point-to-point FTTH, clauses 1 1.5 Remote 
management in optical networks (GPON) and 1 1.6 Physical alarms for GPON. 

No local management features are required, except for GPON where a means is needed to configure on each ONT an 
identifier of the subscriber it is serving, as specified in 143). 

11.1 Remote physical layer monitoring capabilities 

135) [GPON]The NT WAN interface must provide physical loopback capability, that are activated on remote action 
by the LT and enable the operator to differentiate a physical media outage from an NT failure. On WAN 
interfaces two loopback points can be identified, one at the transceiver end, the other on the ONT backplane 
interface. 

136) [GPON and P2P FTTH] The NT Wan interface working status and configuration figures may be monitored 
using the attributes listed in Multi-Source- Agreements such as SFF-8472 [i.31]. Note that SFF-8472 [i.31] was 
originally specified for SFF/SFP modules, but it does not implicate any particular requirement over the form 
factor of the WAN interface (i.e. no limitation to SFF/SFP). 

137) [GPON] The NT WAN interface must be able to provide transmission statistics with BER indicators 
corresponding to the transmission MAC framing used. 

138) [GPON and P2P FTTH] Compatibility with external measurement tools may be assured for those operators 
using "live" monitoring by filtering of the monitoring signal at the NT receiver (For instance by optical 
wavelength filtering through an optical time domain reflectometer). 

139) [P2P FTTH] Support of Link layer or EFM 0AM (IEEE 802.3ah [i.5]) fault management specifications: 
Remote Loopback and Link Fault Event. 

140) [P2P FTTH] Support of Connectivity Fault Management (IEEE 802. lag [i.9]): Connectivity Check Message 
and Linktrace. 
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1 1 .2 Local management and configuration 

141) No external Console port must be present. 

142) [xDSL and PtoP] It must not be possible to access locally the NT using any management interface over LAN 
ports (i.e. web-based GUI, SSH, telnet, etc.). 

[GPON] 

Because GPON is a shared media, a means is needed to configure through each ONT a password called hereafter 
"registration ID" that identifies the subscriber it is serving. 

The registration ID will be communicated by the ONT to the OLTwhen ranging together for the first time. After an 
ONT and OUT pair have once ranged successfully, the registration ID is not used any more, as the serial number of the 
ONT is remembered and recognized by the OUT. To make sure that it cannot be spoofed, the validity of the registration 
ID that identifies a given subscriber can be limited, through configuration of the OLTby the access network provider, 
to a given PON and a given period of time, according to where and when the access network provider expects to 
connect a new ONT for that subscriber, and the rate at which an OUT accepts to receive different registration ID from a 
given ONT will also be limited. 

This registration ID allows to activate the services as soon as the ONT is installed, while avoiding any pre-association 
between physical devices and subscribers, therefore easing the management of devices stocks and replacement of faulty 
devices, possibly by customers themselves. This registration ID based provisioning method (as opposed to the serial 
number based provisioning method) will most probably be annexed within one year time to the ITU-T Recommendation 
G.984 standard as a best practice generating very significant operational cost savings. 

The following requirements aim at providing a captive portal local to the ONT, as a convenient means to communicate, 
through any ONT LAN interface, this registration ID identifying the subscriber. 

143) Local management via LAN ports must be limited to initiate the GPON NT with a registration ID that will 
enable the ONT to be identified by the OLT as pertaining to a given subscriber. 

144) The NT must implement one logical IP interface, accessible through any of its LAN ports and any VLAN ID, 
and activate this logical IP interface only when it has not ever been ranged previously on any PON. 

145) The IP interface specified in 144) must be pre-provisioned in factory with any public IP address. 

146) The NT must implement a DHCP server, a PPPoE server, a DNS and a HTTP server, accessible through any 
of its LAN ports and any VLAN ID, and activate these servers only when it has not ever been ranged 
previously on any PON. 

147) The DHCP server specified in 146) must respond to any DHCP request (addressed to the ONT on the well 
known port 67), whatever the parameters the DHCP request contain, and return an IP configuration with an IP 
subnet to which the NT's local IP address belongs, together with the NT's local IP address as a Domain Name 
Server and a Lease Time of 60 seconds. 

148) The PPPoE server specified in 146) must respond to any PPPoE request (addressed to the ONT on the well 
known Ethertype 0x8863), whatever the parameters the PPPoE request contain, and return an IP configuration, 
together with the NT's local IP address as a Domain Name Server. The period of LCP keepalive messages 
must be 30 seconds. 

149) The Domain Name Server specified in 146) must respond to any DNS request (addressed to the ONT on the 
well known port 53), whatever the targeted domain name it contains, with the NT's local IP address, and a 
Time To Live of 60 seconds. 

150) The HTTP server specified in 146) must respond to any HTTP request, whatever the targeted URL it contains, 
and return an HTML page, with no-cache directive, that provides a graphical interface asking to enter a 
registration ID. 

151) The ONT must switch off all its LAN interfaces while ranging with the OLT. 

152) The ONT must store the registration ID in a non volatile memory. 

153) The ONT must store in a non volatile memory whether it has ever been ranged previously on any PON. 
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154) The ONT must implement as described in 8) a physical means to allow a user forcing the ONT returning to its 
factory state (i.e. to flush its memory from the information specified in 152) and 153)). 

1 1 .3 TCP/IP based remote management 

The following requirements apply in case remote management option is required and based on a TCP/IP solution; in 
any case these do not apply to GPON NT which is fully managed by OMCI. 

155) Remote management, using DSL Forum CWMP protocol (TR-069 [i.29]). 

156) For ensuring a secure CWMP communication between the NT and the TR-069 ACS, it is recommended that 
SSL/TLS is used, the CPE is preconfigured with one or more trusted root certificates for authenticating the 
ACS, the CPE is preconfigured with the credentials for being authenticated by the ACS (with either basic or 
Digest HTTP authentication) and to authenticate the connection requests of the ACS. 

157) TR-069 [i.29] compliant firmware upgrade 

Compliance to DSL Forum PD-128 [i.30] interoperability test for Firmware download. 

Firmware upgrade, to allow future firmware releases and functionalities (i.e. patches, complete QoS 
features, IPv6 support, etc.). 

158) Compliance to DSL Forum data models for InternetGatewayDevice (a subset of appropriate parameters from 
TR-098 [i.28] and WT-107 [i.27]), as described in the following requirements. 

159) Provisioning and device configuration 

Basic InternetGatewayDevice parameters: Devicelnfo, ManagementServer, Time. 

VDSL2 WAN interface management parameters (WANDevice. { i } .WANDSLInterfaceConfig). 

Ethernet LAN interface management parameters (LANDevice. { i } .LANEthernetlnterfaceConfig) . 

Ethernet LAN hosts (LANDe vice. {i}. Hosts). 

L2 services configuration parameters (Layer2Bridging), as specified in clauses 6.2 L2 Ethernet features 
and 7 LAN interfaces. 

QoS upstream configuration parameters (QueueManagement), as specified in clause 9 LAN- WAN QoS 
functionalities. 

management connection configuration parameters (WANDevice. { i } . WANConnectionDevice. { i } .- 
WANIPConnection. { i } ; WANDevice. { i } .WANConnectionDevice. { i } . WANPPPConnection. { i } ) . 

160) Assurance for troubleshooting: 

xDSL interface supervision (WANDevice. { i } .WANDSLInterfaceConfig.TestParams). 
xDSL diagnostics functionalities (WANDSLDiagnostics). 
device diagnostics functionalities (SelfTestDiagnostics). 

161) Assurance for monitoring (traffic descriptor monitoring and statistic counters both on WAN and LAN side, for 
each portA^LAN/CoS, and on QoS engine): 

xDSL interface statistics (WANDevice. { i } . WANCommonlnterfaceConfig; WANDevice. { i } .- 
WANDSLInterfaceConfig.Stats). 

LAN interface statistics (L ANDe vice. {i}.LANEthernetInterfaceConfig.{i}. Stats). 

statistics about policing (more parameters to be specified in QueueManagement.Policer.ji}), for 
conforming, partial conforming and non conforming traffic, and QoS (more parameters to be specified in 
QueueManagement.Queue.ji}), for output and dropped traffic. 
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management connection statistics (WANDevice. { i } . WANConnectionDevice. { i } .- 
WANIPConnection. { i } . Stats ; WANDevice. { i } .WANConnectionDevice. { i } .- 
WANPPPConnection. { i } .Stats). 

162) Event/Fault management, to allow fast problems detection: 

support for active and passive notification; 
support for scheduled Inform. 

1 1 .4 Alternative management solution for Point-to-Point FTTH 

This clause describes the requirements for an alternative management solution that for configuration and fault 
management tasks does not rely on communications with a remote management system. This solution ensures robust, 
trouble free and secure operation of the NT and does not require integration with the OSS layer. It is specifically 
targeted as a low cost solution for Point-to-Point FTTH access. The main characteristics of this solution are: 

• Configuration management for multiple LAN-ports supported by a dynamic VLAN ID translation scheme. 

• Fault management supported by standard Ethernet 0AM (IEEE 802.3ah [i.5] and IEEE 802. lag [i.9]). 

• Lightweight management interface only for emergency firmware upgrades. 

163) Configuration management supported by a dynamic VLAN ID translation scheme (see note) according to the 
following specifications: 

NOTE: KPN Patent Pending. 

The IEEE 802. Iq [i. 1 1] 12-bit VLAN ID has in the context of the NT the following convention: 

■ The four most significant bits (left-most bits) identify the physical LAN-port. This allows future 
support up to 16 addressable physical LAN-ports. 

■ The eight least significant bits (right-most bits) identify the service. This allows up to 255 
addressable services (per LAN-port). 

The NT processes egress Ethernet Frames on a LAN-port according to the following conventions: 

■ Rewrite the four most significant bits of the VLAN ID with zeroes. 

■ Remove the VLAN tag if the eight least significant bits correspond to a value of 128. 

■ Forward the Ethernet Frame to the internal management interface if the VLAN ID has a value of 

255. 

■ Drop the Ethernet Frame if the eight least significant bits correspond to a value of 255 and the four 
most significant bits correspond to a value in the range from 1 to 15. 

■ Drop the Ethernet Frame if the eight least significant bits correspond to a value of 0. 

The NT processes ingress Ethernet Frames on a LAN-port according to the following conventions: 

■ Rewrite the four most significant bits of the VLAN ID with the corresponding physical LAN-port 
number. 

■ Add a VLAN tag for untagged Ethernet Frames. The four most significant bits of the VLAN ID 
shall identify the physical LAN-port number. The eight least significant bits of the VLAN ID shall 
correspond to a value of 128. The three 802. Ip bits shall correspond to a value of 0. 

■ Rewrite the VLAN tag if the VLAN ID has a value of 0. The four most significant bits of the 
VLAN ID shall identify the physical LAN-port number. The eight least significant bits of the 
VLAN ID shall correspond to a value of 128. The three 802. Ip bits shall correspond to a value of 0. 

■ Drop the Ethernet Frame if the eight least significant bits correspond to a value of 255 and the four 
most significant bits correspond to a value in the range from to 15. 
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■ Drop the Ethernet Frame if the VLAN ID has a value of 128 or 255. 
Upstream CoS is supported according to the following conventions: 

■ The NT supports a weighted fair queuing mechanism based on four upstream queues. These queues 
have the following weights assigned: 1:2:4:8. 

■ The service ID section of the VLAN ID (eight least significant bits) is divided into four blocks. 
Each block corresponds to one of the four upstream queues and Ethernet Frames are forwarded 
accordingly. 

■ Untagged Ethernet Frames are assigned to the queue with the lowest weight. 

164) Rudimentary support for connecting to a remote management system that is used for accidental firmware 
upgrades according to the following specifications: 

Internal management interface with a L3 IPv4 protocol stack for assuring basic NT network connectivity 
at the IP layer to the Network. 

WAN-side DHCP client, in order to obtain an IP address directly from the network DHCP server and use 
an IPoE encapsulation. 

The DHCP Discovery message shall have a heartbeat between 60 and 300 seconds. This heartbeat shall 
persist as long as the internal management interface is not active. By default there is no connection with 
the management system. The connection with the management system will only be established for the 
duration of the upgrade of the NT-installed base. 

The NT shall be able to retrieve the IP-address of the remote management system during the DHCP 
message sequence using DHCP option 43, DHCP option 66 or combination of these options. 

As soon as the internal management interface becomes active, the NT shall verify its firmware version 
with the remote management system and shall download via TFTP a new firmware if available. 

The NT shall verify the downloaded firmware using a CRC or MD5 checksum before installing the 
firmware and rebooting itself. 

1 1 .5 Remote management in optical networl<s (GPON) 

OMCI (ONT Management and Control Interface) is the management protocol used for optical network management in 
GPON technologies. 

165) ONTs/ONUs complies with the applicable sections of ITU-T Recommendation G.984.4 [i.lO] and referenced 
documents. All applicable managed entities in table 1 of ITU-T Recommendation G.984.4 [i.lO] required to 
support the features and services outlined in the present document are supported. 

166) The ONT must be able to support firmware upgrade using methods described in 165). 

1 1 .6 Piiysical alarms 

Physical alarms for all networks 

167) The system is able to support dry loop to report power alarm (dying gasp). 

168) The system is able to support dry loop to report intrusion alarm. 
Physical alarms in optical networks (GPON) 

169) ONTs/ONUs complies with the applicable sections of ITU-T Recommendation.G.984.3 [i.lO]. 

170) The G-PON system is able to monitor, set thresholds and generate alarm conditions for laser drive current at 
the ONT/ONU. 

171) The G-PON system is able to monitor, set thresholds and generate alarm conditions for optical output power at 
the ONT/ONU. 
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172) The G-PON system is able to monitor, set thresholds and generate alarm conditions for receiver optical power 
at the ONT/ONU. 

173) The GPON system is able to support dry loop to report environmental alarm. 



12 Memory requirements related to firmware upgrade 
feature 

174) If remote firmware upgrade is supported, the memory size must be large enough to allow the storage of a 
backup version of the firmware, in order to prevent any unrecoverable crash during the firmware upgrade 
procedure. 



1 3 Factory default configuration 

Only generic statements have to be reported in this clause, letting every Operator define the localized factory default 
configuration. 

175) Flexibility do define a default setting of parameters in compliance with the needs of the specific operator is 
required. 
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